36.1 KB · ⇊ 11 parts · ⤓ Micron 36.1 KB · ⤓ HTML 79.4 KB

top

In mwcqtelecomunicazioni e mwcginformatica lmwcw'mwdaHyperText Transfer Protocol (mwdqHTTP) (mwdglett. "protocollo per il trasferimento di ipertesto") è un mwdwprotocollo mweaapplicativo usato come principale sistema per la mweqtrasmissione d'mweginformazioni su mwewinternet. Le specifiche del protocollo sono gestite dal mwfaWorld Wide Web Consortium (mwfqW3C). Un mwfgserver HTTP generalmente resta in ascolto delle richieste dei mwfwclient sulla mwgaporta mwgqTCP 80.

• Storia

• Riepilogo delle versioni del protocollo HTTP

• Funzionamento

• Messaggio di richiesta

• Messaggio di risposta

• Tipo di connessione

• Esempi di messaggi HTTP

• Richiesta GET e risposta di successo

• Richiesta GET e risposta di redirezione permanente

• Richiesta POST e risposta di redirezione temporanea

• Richieste utili nella versione 1.0

• Versioni sicure

• Streaming HTTP

• Note

• Bibliografia

• Voci correlate

• Altri progetti

• Collegamenti esterni

La prima versione dell'HTTP, la 0.9, risale alla fine degli mwhqanni 1980 e costituiva, insieme con il linguaggio mwhgHTML e gli mwhwURL, il nucleo base del mwiaWorld Wide Web (WWW) mwiqglobal information initiative sviluppata da mwigTim Berners-Lee al mwiwCERN di mwjaGinevra per la condivisione delle informazioni tra la comunità dei mwjqfisici delle alte energie. Prima di HTTP il protocollo di riferimento per tali scopi era il più semplice e leggero mwjgFTP.

Con la diffusione di mwkaNCSA Mosaic, un mwkqbrowser grafico di facile uso, il WWW conobbe un successo crescente e divennero evidenti alcuni limiti della versione 1.0 del protocollo, in particolare:

• l'impossibilità di ospitare più siti web sullo stesso mwlaserver (mwlqvirtual host);

• il mancato riuso delle connessioni disponibili;

• l'insufficienza dei meccanismi di mwmqsicurezza.

La prima versione effettivamente disponibile del protocollo, la HTTP/1.0, venne implementata dallo stesso Berners-Lee nel 1991 e proposta come mwngRFC 1945cite-ref-1[1] all'ente normatore mwowIETF nel 1996.

Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato come mwpwRFC 2068cite-ref-2[2] nel 1997 e successivamente aggiornato nel 1999 come descritto dal mwraRFC 2616cite-ref-3[3].

La nuova versione del protocollo, mwtaHTTP/2, è stata pubblicata nella mwtqRFC 7540cite-ref-4[4] nel maggio 2015.

La terza versione del protocollo, mwvqHTTP/3, è stata pubblicata nella mwvgRFC 9114cite-ref-5[5] il 6 giugno 2022.

L'HTTP è un protocollo che lavora con un'architettura di tipo mwxqclient/server: il mwxgclient esegue una richiesta e il mwxwserver restituisce la risposta mandata da un altro host. Nell'uso comune il client corrisponde al mwyabrowser e il server la macchina su cui risiede il mwyqsito web. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta (detti mwygHTTP requests) e messaggi risposta (detti mwywHTTP responses).

HTTP differisce da altri protocolli di mwzqlivello 7 come mwzgFTP, per il fatto che le mwzwconnessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono dei mwaacollegamenti (link) a pagine ospitate da altri server diminuendo così il numero di connessioni attive limitandole a quelle effettivamente necessarie con aumento quindi di efficienza (minor carico e occupazione) sia sul client che sul server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (mwaqstateless) della mwagsessione di navigazione costringe a utilizzare dei metodi alternativi — tipicamente basati sui mwawcookie — per conservare lo stato dell'utente.

Il messaggio di richiesta è composto da quattro parti:

• riga di richiesta (mwcarequest line);

• sezione mwcgheader (informazioni aggiuntive);

• riga vuota (CRLF: i due caratteri mwdamwdqcarriage return e mwdgline feed);

• mweabody (corpo del messaggio).

La riga di richiesta è composta da metodo, mwewURI e versione del protocollo. Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:

• mwfgGET

• mwgaPOST

• mwggHEAD

• mwhaPUT

• mwhgDELETE

• mwiaPATCH

• mwigTRACE

• mwjaOPTIONS

• mwjgCONNECT

l'URI, mwkauniform resource identifier (identificatore univoco di risorsa), indica l'oggetto della richiesta (ad esempio la mwkqpagina web che si intende ottenere).

I metodi HTTP più comuni sono mwkwGET, mwlaHEAD e mwlqPOST. Il metodo mwlgGET è usato per ottenere il contenuto della risorsa indicata come URI (come può essere il contenuto di una pagina HTML). mwlwHEAD è analogo a mwmaGET, ma restituisce solo i campi dell'header, ad esempio per verificare la data di modifica del file. Una richiesta con metodo mwmqHEAD non prevede l'uso del mwmgbody.

Il metodo mwnaPOST è usato di norma per inviare informazioni al server (ad esempio i dati di un mwnqform). In questo caso l'URI indica che cosa si sta inviando e il mwngbody ne indica il contenuto.

Gli header di richiesta più comuni sono:

mwowHost: nome del server a cui si riferisce l'URL. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette l'uso dei mwpavirtual host basati sui nomi.

mwpgUser-Agent: identificazione del tipo di client: tipo browser, produttore, versione ecc...

mwqaCookie: utilizzati dalle applicazioni web per archiviare e recuperare informazioni a lungo termine sul lato client. Spesso usati per memorizzare un token di autenticazione o per tracciare le attività dell'utente.

Il messaggio di risposta è di tipo testuale ed è composto da quattro parti:

• riga di stato (mwrqstatus-line);

• sezione mwrwheader;

• riga vuota (CRLF: i 2 caratteri carriage return e line feed);

• mwsgbody (contenuto della risposta).

La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:

• mwuq1xx: Informational (messaggi informativi)

• mwuw2xx: Successful (la richiesta è stata soddisfatta)

• mwvq3xx: Redirection (non c'è risposta immediata, ma la richiesta è sensata e viene detto come ottenere la risposta)

• mwvw4xx: Client error (la richiesta non può essere soddisfatta perché sbagliata)

• mwwq5xx: Server error (la richiesta non può essere soddisfatta per un problema interno del server)

I codici di risposta più comuni sono:

• mwxq200 OK. Il server ha fornito correttamente il contenuto nella sezione mwxgbody.

• mwya301 Moved Permanently. La risorsa che abbiamo richiesto non è raggiungibile perché è stata spostata in modo permanente.

• mwyg302 Found. La risorsa è raggiungibile con un altro URI indicato nel header Location. Di norma i browser eseguono la richiesta all'URI indicato in modo automatico senza interazione dell'utente.

• mwza400 Bad Request. La risorsa richiesta non è comprensibile al server.

• mwzgmwzw404 Not Found. La risorsa richiesta non è stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando l'URI è stato indicato in modo incorretto, oppure è stato rimosso il contenuto dal server.

• mw0q500 Internal Server Error. Il server non è in grado di rispondere alla richiesta per un suo problema interno.

• mw0w502 Bad Gateway. Il server web che agisce come mw1amw1qreverse proxy non ha ottenuto una risposta valida dal server di mw1gmw1wupstream.

• mw2q505 HTTP Version Not Supported. La versione di http non è supportata.

Gli header della risposta più comuni sono:

• mw3gServer. Indica il tipo e la versione del server. Può essere visto come l'equivalente dell'header di richiesta mw3wUser-Agent

• mw4qContent-Type. Indica il tipo di contenuto restituito. La codifica di tali tipi (detti mw4gMedia type) è registrata presso lo mw4wIANA (Internet Assigned Number Authority); essi sono detti tipi mw5aMIME (Multimedia Internet Mail Extensions), la cui codifica è descritta nel documento mw5qRFC 1521. Alcuni usuali tipi MIME incontrati in una risposta HTTP sono:

• mw6atext/html Documento HTML

• mw6gtext/plain Documento di testo non formattato

• mw7atext/xml Documento mw7qXML

• mw7wimage/jpeg Immagine di formato mw8aJPEG

Il client può chiedere al server, nel messaggio di richiesta, di utilizzare due tipi di comunicazione:

• Non persistente: Per ogni richiesta e relativa risposta, viene stabilita una connessione TCP dedicata.

• Persistente: Ogni richiesta e relativa risposta è trasferita utilizzando la stessa connessione TCP. È il comportamento predefinito di HTTP 1.1.

Da un lato, le connessioni non persistenti introducono una latenza aggiuntiva rispetto a quelle persistenti di almeno tre mw9wRound Trip Time (RTT). Infatti, al termine di ogni risposta da parte del server si rendono necessari:

• 1,5 o 2 RTT per la chiusura della connessione corrente, con la sua stretta di mano conclusiva a tre o quattro passaggi di FIN e ACK (mw-gthree- o mw-wfour-way handshake).

• 1,5 RTT per l'apertura della nuova connessione, per i tre passaggi di SYN e ACK.

D'altro canto, le connessioni persistenti precludono il parallelismo nelle comunicazioni, giacché il client che abbia diverse richieste da inviare allo stesso server è costretto a evaderle sequenzialmente, una dopo l'altra. Per queste ragioni, i browser solitamente sfruttano le complementarità prestazionali delle due politiche di comunicazione per massimizzare la loro efficienza: solitamente aprono con ogni server diverse connessioni TCP in parallelo, su cui comunicano con strategia persistente.

Seguono esempi di messaggi di richiesta e risposta HTTP/1.1.

Gli esempi riguardano il recupero di contenuti su questa enciclopedia web e possono essere riprodotti — e quindi verificati — sul proprio PC copiando e incollando il testo con un client TCP (per esempio: mwaqetelnet it.wikipedia.org 80 nel caso di URL http://), oppure client TCP con supporto SSL (ad esempio: mwaqiopenssl s_client -connect it.wikipedia.org:443 nel caso di URL https://).

Ai fini della riproduzione si annota che:

• l'unico header obbligatorio nella richiesta HTTP/1.1 è lmwaqy'mwaqcheader mwaqgHost contenente la parte host dell'URL (come scritto sopra);

• in genere i browser aggiungono lmwaqo'mwaqsheader mwaqwAccept-Encoding per specificare la possibilità di ricevere la risposta in formato compresso. L'header è eliminato per rendere leggibile la risposta (es: mwaq0Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity);

• al termine degli header è obbligatoria sempre una riga vuota (ossia due "a capo" consecutivi)

• le parti identificate con [...] indicano le parti omesse

Recupera la risorsa web presente all'URL mwarihttps://it.wikipedia.org/wiki/Pagina_principale

Risposta di successo (200 OK):

Qui il client recupera l'URL mwaymhttp://it.wikipedia.org/wiki/Pagina_principale (differisce dal precedente poiché http invece di https).

La richiesta rimane la stessa dell'esempio precedente.

La risposta cambia esponendo un codice di spostamento permanente (mwayy301 Moved Permanently):

Questa è una richiesta mwaayPOST per modificare le proprie preferenze di wikipediano con il tema "Cologne Blue" (la sottostringa mwaac&wpskin=cologneblue nella prima riga del corpo della richiesta mwaagPOST)

Risposta HTTP di redirezione temporanea (302 Found) rimanda alla pagina per il login

La GET nella versione HTTP/1.0 risulta comoda per le docenze, si può effettuare con una sola riga perché nella versione 1.0 del protocollo non era obbligatorio inserire l'header "Host:"

Per eseguirla si fa:

Si ricorda di lasciare una riga vuota dopo la richiesta. Attendere la risposta dal webserver...

Risulta allo stesso modo molto comodo effettuare la richiesta mwat4HEAD del protocollo che restituisce le sole intestazioni con:

Dal momento che tutto il traffico HTTP è anonimo e in chiaro, sono state sviluppate diverse alternative per garantire differenti livelli di mwauksicurezza, in termini di:

• mwauwcifratura del mwau0traffico;

• verifica di mwau8integrità del traffico;

• mwaveautenticazione del server;

• autenticazione dell'utente.

La prima proposta venne direttamente da mwavqNCSA, con le versioni server 1.1 e client 2.2 che supportavano un meccanismo di autenticazione utente e cifratura dati basati su messaggi formato PEM e chiavi mwavyPGP.

In seguito, sono state standardizzate due versioni mwavgsicure del protocollo HTTP chiamate SHTTP e mwavoHTTPS. La prima, modellata sulla posta cifrata mwavsS/MIME, è ormai caduta in disuso e prevede meccanismi crittografici a livello di mwavwmwav0payload: le richieste e gli header vengono scambiati in chiaro mentre il contenuto della pagina viene cifrato come una struttura mwav4MIME mwav8multipart. Il meccanismo HTTPS, inventato da mwawaNetscape, usa invece il sottostante canale mwawecifrato a livello di mwawitrasporto mediante mwawmSSL o mwawqTLS per impedire l'intercettazione di qualsiasi parte della transazione. Entrambi i protocolli possono garantire l'identità del mittente, ma solo SHTTP è in grado di garantire anche l'integrità del contenuto dopo averlo, ad esempio, memorizzato su un disco.

La fruizione nelle pagine WEB di materiale mwawcmultimediale, quale mwawgaudio o mwawkvideo viene gestito in modo del tutto analogo al mwawodownload dei file, tramite un caricamento progressivo o distribuzione progressiva, in cui il file viene scaricato in modo progressivo dall'inizio alla fine (tramite i protocolli mwawsmwawwReal Time Streaming Protocol e mwaw0mwaw4Real-time Transport Protocol) e nel caso il mwaw8bit-rate sia eccessivo per la rete che lo trasporta può verificarsi un continuo ricaricamento del mwaxabuffer

Per evitare questi inconvenienti esistono altri sistemi alternativi, che permettono l'adattamento del file alla rete dell'utente finale, questi sistemi sono caratterizzati dai protocolli:

• mwaxqSmooth Streaming, ideato da Microsoftcite-ref-6[6]cite-ref-7[7]

• mwax8HTTP Dynamic Streaming soluzione ideata da Adobe

• mwayimwaymHTTP Live Streaming soluzione ideata da Apple

• mwayuOctoshape è una piattaforma proprietaria di streaming multimediale, che utilizza la tecnologia per offrire un mwaycthroughput migliore e rompere la congestione nell'mwaygultimo miglio. Ha la possibilità di utilizzare una suite di tecnologie mwaykmulticast per ridurre al minimo la larghezza di banda per qualsiasi mwayoCDN, mwaysISP, emittente o del fornitore dell'ultimo miglio.

Per contro queste soluzioni sono notevolmente più complesse rispetto alle tradizionali tecnologie di streaming. Alcune delle considerazioni documentate riguardano lo stoccaggio, i costi aggiuntivi per la codifica e la difficoltà nel mantenimento della qualità globale. Ci sono state anche alcune dinamiche interessanti trovate intorno alle interazioni complesse fra logica adattiva bit rate in competizione con complessa logica di controllo del flusso TCP.cite-ref-8[8]cite-ref-9[9]

cite-note-11. ↑ mwazs(mwazwmwaz0EN) mwaz4mwaz8RFC 1945, su mwa0adatatracker.ietf.org, mwa0eInternet Engineering Task Force.mwa0i

cite-note-22. ↑ mwa0y(mwa0cmwa0gEN) mwa0kmwa0oRFC 2068, su mwa0sdatatracker.ietf.org, mwa0wInternet Engineering Task Force.mwa00

cite-note-33. ↑ mwa1e(mwa1imwa1mEN) mwa1qmwa1uRFC 2616, su mwa1ydatatracker.ietf.org, mwa1cInternet Engineering Task Force.mwa1g

cite-note-44. ↑ mwa1w(mwa10mwa14EN) mwa18mwa2aRFC 7540, su mwa2edatatracker.ietf.org, mwa2iInternet Engineering Task Force.mwa2m

cite-note-55. ↑ mwa2c(mwa2gmwa2kEN) mwa2omwa2sRFC 9114, su mwa2wdatatracker.ietf.org, mwa20Internet Engineering Task Force.mwa24

cite-note-66. ↑ mwa3imwa3mmwa3qIIS Smooth Streaming Technical (mwa3umwa3yPDF), su mwa3cdownload.microsoft.com mwa3g(archiviato dall'mwa3kurl originale il 5 giugno 2011).

cite-note-77. ↑ mwa30mwa34mwa38Smooth Streaming, su mwa4aiis.net.

cite-note-88. ↑ mwa4qmwa4umwa4yAn Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP (mwa4cmwa4gPDF), su mwa4kcc.gatech.edu mwa4o(archiviato dall'mwa4surl originale il 17 ottobre 2011).

cite-note-99. ↑ mwa48mwa5amwa5eIs adaptive bit rate the yellow brick road, or fool's gold for HD streaming?, su mwa5ifierceonlinevideo.com. mwa5mURL consultato il 20 settembre 2011 mwa5q(archiviato dall'mwa5uurl originale il 7 settembre 2011).

• mwa5kRFC 1945 (Specifiche HTTP 1.0)

• mwa5sRFC 2616 (Specifiche HTTP 1.1)

• mwa50RFC 7540 (Specifiche HTTP 2.0)

• mwa58RFC 9114 (Specifiche HTTP 3.0)

• mwa6mDo not track header

• mwa6uFile Transfer Protocol (FTP)

• mwa6cHTTP tunneling

• mwa6kProtocollo di rete

• mwa6sSPDY

• mwa60World Wide Web Consortium

Altri progetti

• Wikizionario

• Wikimedia Commons

• Wikizionario contiene il lemma di dizionario «HTTP»

• Wikimedia Commons contiene immagini o altri file sull'Hypertext Transfer Protocol

• (EN) Sito ufficiale, su httpwg.org.

• citereftreccani-itHTTP, su Treccani.it – Enciclopedie on line, Istituto dell'Enciclopedia Italiana.

• citerefsapere-itHTTP, su sapere.it, De Agostini.

• citereflessico-del-xxi-secoloHTTP, in Lessico del XXI secolo, Istituto dell'Enciclopedia Italiana, 2012.

• citerefenciclopedia-della-matematicaHTTP, in Enciclopedia della Matematica, Istituto dell'Enciclopedia Italiana, 2013.

• citerefbritannica-com(EN) HTTP, su Enciclopedia Britannica, Encyclopædia Britannica, Inc.

• citerefopen-library(EN) Opere riguardanti HTTP (Computer network protocol), su Open Library, Internet Archive.

• citereffoldoc(EN) Denis Howe, Hypertext Transfer Protocol, in Free On-line Dictionary of Computing. Disponibile con licenza mwa7qGFDL